<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <title>Boost Formal Review Process</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <link rel="icon" href="/favicon.ico" type="image/ico" />
  <link rel="stylesheet" type="text/css" href=
  "../style-v2/section-community.css" />
  <!--[if IE]> <style type="text/css"> body { behavior: url(../style-v2/csshover.htc); } </style> <![endif]-->
</head><!--
Note: Editing website content is documented at:
https://www.boost.org/development/website_updating.html
-->

<body>
  <div id="heading">
    <!--#include virtual="/common/heading.html" -->
  </div>

  <div id="body">
    <div id="body-inner">
      <div id="content">
        <div class="section" id="intro">
          <div class="section-0">
            <div class="section-title">
              <h1>Boost Formal Review Process</h1>
            </div>

            <div class="admonition">
              <h2>Before Requesting a Formal Review</h2>

              <p><strong>Read and follow the Boost <a href=
              "/development/submissions.html">submission
              process</a>.</strong> There are several steps a library author
              must take before a formal review is requested.</p>
            </div>

            <div class="section-body">
              <ul class="toc">
                <li>
                  <a href="#Introduction">Introduction</a>
                </li>

                <li>
                  <a href="#Comments">What to include in Review Comments</a>
                </li>

                <li>
                  <a href="#Results">Results</a>
                </li>

                <li>
                  <a href="#Review_Manager">Notes for Review Managers</a>
                </li>

                <li>
                  <a href="#Submitters">Notes for Library Submitters</a>
                </li>

                <li>
                  <a href="#Maintainer">Library Maintainer's Rights and
                  Responsibilities</a>
                </li>

                <li>
                  <a href="#Wizard">Review Wizard</a>
                </li>

                <li>
                  <a href="#Fast-Track">Fast Track Reviews</a>
                </li>
              </ul>

              <h2><a name="Introduction" id=
              "Introduction"></a>Introduction</h2>

              <p>Proposed libraries are accepted into Boost only after
              undergoing a formal review, where Boost mailing list members
              comment on their evaluation of the library.</p>

              <p>The final "accept" or "reject" decision is made by the
              <a href="#Review_Manager">Review Manager</a>, based on the
              review comments received from boost mailing list members.</p>

              <p>Boost mailing list members are encouraged to submit Formal
              Review comments:</p>

              <ul>
                <li>Publicly on the mailing list or the <a href=
                "http://blincubator.com">Boost Library Incubator</a>.
                </li>

                <li>Privately to the Review Manager.</li>
              </ul>

              <p>Private comments to a library submitter may be helpful to
              her or him, but won't help the Review Manager reach a decision,
              so the other forms are preferred.</p>

              <h2><a name="Comments" id="Comments"></a>What to include in
              Review Comments</h2>

              <p>Your comments may be brief or lengthy, but basically the
              Review Manager needs your evaluation of the library. If you
              identify problems along the way, please note if they are minor,
              serious, or showstoppers.</p>

              <p>The goal of a Boost library review is to improve the library
              through constructive criticism, and at the end a decision must
              be made: is the library good enough at this point to accept
              into Boost? If not, we hope to have provided enough
              constructive criticism for it to be improved and accepted at a
              later time. The Serialization library is a good example of how
              constructive criticism resulted in revisions resulting in an
              excellent library that was accepted in its second review.</p>

              <p>Here are some questions you might want to answer in your
              review:</p>

              <ul>
                <li>What is your evaluation of the design?</li>

                <li>What is your evaluation of the implementation?</li>

                <li>What is your evaluation of the documentation?</li>

                <li>What is your evaluation of the potential usefulness of
                the library?</li>

                <li>Did you try to use the library? With what compiler? Did
                you have any problems?</li>

                <li>How much effort did you put into your evaluation? A
                glance? A quick reading? In-depth study?</li>

                <li>Are you knowledgeable about the problem domain?</li>
              </ul>

              <p>And finally, every review should answer this question:</p>

              <ul>
                <li>Do you think the library should be accepted as a Boost
                library? Be sure to say this explicitly so that your other
                comments don't obscure your overall opinion.</li>
              </ul>

              <p>Many reviews include questions for library authors. Authors
              are interested in defending their library against your
              criticisms; otherwise they would not have brought their library
              up for review. If you don't get a response to your question
              quickly, be patient; if it takes too long or you don't get an
              answer you feel is sufficient, ask again or try to rephrase the
              question. Do remember that English is not the native language
              for many Boosters, and that can cause misunderstandings.</p>

              <p>E-mail is a poor communication medium, and even if messages
              rarely get lost in transmission, they often get drowned in the
              deluge of other messages. Don't assume that an unanswered
              message means you're being ignored. Given constructively,
              criticism will be taken better and have more positive effects,
              and you'll get the answers you want.</p>

              <h2><a name="Results" id="Results"></a>Results</h2>

              <p>Within a reasonable time after the conclusion of the comment
              period, the Review Manager will post a message to the mailing
              list saying if the library has been accepted or rejected. A
              rationale is also helpful, but its extent is up to the Review
              Manager. If there are suggestions, or conditions that must be
              met before final inclusion, they should be stated. Concerns
              about the timeliness or quality of the review report should be
              brought to the Review Wizards off-list.</p>

              <h2><a name="Review_Manager" id="Review_Manager"></a>Notes for
              Review Managers</h2>

              <p>Before a library can be scheduled for formal review, an
              active boost member not connected with the library submission
              must volunteer to be the "Review Manager" for the library.
              Members may contact a library author on- or off-list to express
              interest in managing the review.</p>

              <p>The Review Manager:</p>

              <ul>
                <li>Checks the submission to make sure it really is complete
                enough to warrant formal review. See the <a href=
                "/development/requirements.html">Boost Library Requirements
                and Guidelines</a>. Submitting through the <a href=
                "http://blincubator.com">Boost Library Incubator</a> will
                verify many of the requirements. If necessary, work with the submitter to
                verify the code compiles and runs correctly on several
                compilers and platforms.
                </li>

                <li>Finalizes the schedule with the <a href=
                "#Wizard"></a>Review Wizard and the submitter.
                </li>

                <li>Posts a notice of the review schedule on both the regular
                <strong><a href="mailto:boost@lists.boost.org" class=
                "external">boost mailing list</a></strong> and the
                <strong><a href="mailto:boost-announce@lists.boost.org"
                  class="external">boost-announce</a> mailing list</strong>.

                  <ul>
                    <li>The notice should include a brief description of the
                    library and what it does, to let readers know if the
                    library is one they are interested in reviewing.</li>

                    <li>If the library is known to fail with certain
                    compilers, please mention them in the review notice so
                    reviewers with those compilers won't waste time
                    diagnosing known problems.</li>
                    
                    <li>It is advised to send the notice to each mailing list
                    in a separate e-mail, otherwise online e-mail to news
                    gateways could get confused.</li>

                    <li>If possible, also post the notice to the <a href="https://plus.google.com/communities/106814259809358442744">Google+
                    community</a>.</li>
                  </ul>
                </li>

                <li>Inspects the Boost <a href=
                "/doc/libs/release/libs/libraries.htm">library catalogue</a>
                for libraries which may interact with the new submission.
                These potential interactions should be pointed out in the
                review announcement, and the author(s) of these libraries
                should be privately notified and urged to participate in the
                review.
                </li>

                <li>Urges people to do reviews if they aren't
                forthcoming.</li>

                <li>Follows review discussions regarding the library,
                moderating or answering questions as needed.</li>

                <li>Asks the <a href="#Wizard">review wizard</a> for
                permission to extend the review schedule if it appears that
                too few reviews will be submitted during the review period.
                </li>

                <li>Decides if there is consensus to accept the library, and
                if there are any conditions attached. Consensus is not the
                same as a vote. The Review Manager has discretion to weigh
                opinions based on authority or thoughtfulness.</li>

                <li>Posts a notice of the <a href="#Results">review
                results</a> on the regular <strong><a href=
                "mailto:boost@lists.boost.org">boost</a></strong> mailing
                list, the <strong><a href=
                "mailto:boost-users@lists.boost.org">boost-users</a></strong>
                mailing list, and the <strong><a href=
                "mailto:boost-announce@lists.boost.org">boost-announce</a></strong>
                mailing list.
                </li>
              </ul>

              <p>In other words, it is the Review Manager's responsibility to
              make sure the review process works smoothly.</p>

              <h2><a name="Submitters" id="Submitters"></a>Notes for Library
              Submitters</h2>

              <p>See <a href="/development/submissions.html">Submission
              Process</a> for a description of the steps a library developer
              goes through to get a library accepted by Boost.</p>

              <p>A proposed library should remain stable during the review
              period; it will just confuse and irritate reviewers if there
              are numerous changes. It is, however, useful to upload fixes
              for serious bugs right away, particularly those which prevent
              reviewers from fully evaluating the library. Post a notice of
              such fixes on the mailing list.</p>

              <p>Library improvements suggested by reviewers should normally
              be held until after the completion of review period. If the
              suggested changes might affect reviewer's judgments, post a
              notice of the pending change on the mailing list.</p>

              <h2><a name="Maintainer" id="Maintainer"></a>Library
              Maintainer's Rights and Responsibilities</h2>

              <p>By submitting a library to boost, you accept responsibility
              for maintaining your library or finding a qualified volunteer
              to serve as maintainer. You must be willing to put your library
              and documentation under a Boost-compatible license.</p>

              <p>You will be expected to respond to reasonable bug reports
              and questions in a timely manner and to participate as needed
              in discussions of your library on the boost mailing lists.</p>

              <p>You are free to change your library in any way you wish, and
              you are encouraged to actively make improvements. However, peer
              review is an important part of the Boost process and as such
              you are also encouraged to get feedback from the boost
              community before making substantial changes to the interface of
              an accepted library.</p>

              <p>If at some point you no longer wish to serve as maintainer
              of your library, it is your responsibility to make this known
              to the boost community and to find another individual to take
              your place.</p>

              <p>Libraries which have been abandoned will be put in care of
              the <a href=
              "https://svn.boost.org/trac/boost/wiki/CommunityMaintenance">Community
              Maintenance Team</a>.</p>

              <h2><a name="Wizard" id="Wizard"></a>Review Wizards</h2>

              <p>The Review Wizards coordinate the formal review
              schedule:</p>

              <ul>
                <li>When a formal review is requested for a library:

                  <ul>
                    <li>Approve the review manager based on their
                    participation in the Boost community, including the
                    mailing list, previous reviews, and other forums.</li>

                    <li>Suggest a schedule, after checking (via private
                    email) availability of the review manager and library
                    author.</li>

                    <li>Finalize the schedule, once the review manager
                    verifies the library is actually ready for review.</li>

                    <li>Resolve schedule slips or other issues with review
                    managers and submitters.</li>
                  </ul>
                </li>

                <li>Maintains a schedule of both past and pending reviews, in
                the form of the <a href="review_schedule.html">Review
                Schedule</a> web page.
                </li>

                <li>Resolves questions from review managers and library
                submitters, who sometimes want a third opinion on questions
                such as "Should we extend the review period because
                ...?"</li>

                <li>Monitors the general review process, and makes minor
                adjustments as needed, or queries the list about possible
                major adjustments.</li>
              </ul>

              <p>The role of Boost Review Wizard is currently played by John
              Phillips (johnphillipsithaca at gmail dot com) and Ronald
              Garcia (rxg at cs dot ubc dot ca).</p>

              <h2><a name="Fast-Track" id="Fast-Track"></a>Fast Track
              Reviews</h2>

              <p>To qualify for fast track review:</p>

              <ul>
                <li>The component must be small.</li>

                <li>The technique must be already in use in Boost libraries
                and the new component provides a common implementation.</li>

                <li>A full Boost-conformant implementation is available in
                the sandbox.</li>

                <li>The Review Wizard determines that the proposal qualifies
                for fast track review.</li>
              </ul>

              <p>Procedure:</p>

              <ul>
                <li>The Boost Review Wizard posts a review announcement to
                the main Boost developer's list. The review period will
                normally last for 5 days. No two fast track reviews will run
                in parallel. Fast track reviews may run during full reviews,
                though generally this is to be avoided.</li>

                <li>After the review period ends, the submitter will post a
                review summary containing proposed changes to the reviewed
                implementation.</li>

                <li>The Review Wizard will accept or reject the proposed
                library and proposed changes.</li>

                <li>After applying the proposed changes, the component is
                checked into the repository like any other library.</li>
              </ul>

              <h2><a name="Mini-Reviews" id=
              "Mini-Reviews"></a>Mini-Reviews</h2>

              <p>If a review results in conditions on acceptance, the review
              manager may request a Mini-Review to determine if the
              conditions have been met. The Mini-Review is usually conducted
              by the same review manager.</p>
            </div>
          </div>
        </div>
      </div>

      <div id="sidebar">
        <!--#include virtual="/common/sidebar-common.html" -->
        <!--#include virtual="/common/sidebar-community.html" -->
      </div>

      <div class="clear"></div>
    </div>
  </div>

  <div id="footer">
    <div id="footer-left">
      <div id="revised">
        <p>Revised $Date$</p>
      </div>

      <div id="copyright">
        <p>Copyright Beman Dawes, 2000.</p>
      </div><!--#include virtual="/common/footer-license.html" -->
    </div>

    <div id="footer-right">
      <!--#include virtual="/common/footer-banners.html" -->
    </div>

    <div class="clear"></div>
  </div>
</body>
</html>
